基于出行领域全场景的mock提效探索与实践
The following article is from 哈啰技术 Author 崔焕锐
哈啰业务数据场景痛点
软硬件一体化应用场景
用户从APP端、支付宝小程序、微信小程序、H5和WEB，经过一些核心服务。核心服务通过HTTP或内部的RPC接口，包含用户增长、配置平台、综合平台、用户增长等，对应的基础平台包括存储平台、用户平台、算法平台、开放平台、大数据、地图平台等。物联网目前主要对接单车、电动车、电池、电柜等。
研发测试阶段遇到的痛点
单车这里，红包车数据测试链路过长，手工构造一次数据需要0.5天以上；不同入参返回不同结果，难以构造模拟返回数据。助力车这里，超区断电依赖地图算法模型，测试线下路上跑来跑去模拟临区超区耗时过长。顺风车这里，对接众多第三方平台，迭代回归第三方接口，各种场景返回难以构造。支付这里，异常场景众多，实名认证信息难以构造。换电这里，不同项目并行开发，对方接口未开发的情况下，开发调试成本过高；无法模拟只支持某个时间段的返回结果。电动车这里，通过单测的方式Mock各种场景代码量巨大；部分场景Mock需要研发配合改造代码，侵入性过高，成本较大。
哈啰HiMock和传统Mock的对比
传统Mock在哈啰全场景先天性不足
传统Mock一是代码改动频繁，只要代码变动，case相关代码都需要改动，整体耗时较长；二是链路简单，只支持简单链路的Mock；三是Mock难度上，数据构造难，非本业务线同学如果没有接口文档，不知道如何快速Mock；四是扩展难度较大，仅支持部分软件协议，不能扩展。而哈啰全场景业务特性一是代码改动难，涉及到多个业务方，研发无法及时配合验证迭代需求改动相关代码；二是链路复杂，需要支持前后多端、涉及硬件协议链路的Mock；三是Mock难度上，并行开发时，多个业务同个接口模拟不同的返回，构造成本较大；四是拓展程度上，需要支持软硬件协议数据模拟。
打破传统Mock的设计思路
我们为了打破传统Mock的设计思路，从以下六点设计HiMock。一是低代码，代码开发量少，可以快速搭建框架；二是代码解耦，不需要用户改动任何代码；三是高性能，不影响原有系统的性能指标；四是应用性，用户可以低成本Mock；五是支持前后置场景，如签名、回调、数据库操作等；六是全场景，支持前后端各种协议。
Mock技术支撑全场景业务域的实践
打破传统互联网的软硬件结合的Mock业务架构
首先介绍服务链路，C端用户主要来源于哈啰APP、支付宝小程序、微信小程序，通过HTTP网关，再进入各个业务的入口，包括单车、助力车、电动车、换电、顺风车等，接下来我们协议拦截之后，再去匹配对应规则引擎里配置的规则来看是不是命中了对应的Mock，并去检查对应的静默开关、生效时间、生效范围、延时、参数替换、后置条件，这些都是通过规则引擎拿到对应的数据。我们通过Mock返回的规则，一站式并支持多端。
接下来介绍产品能力，一是Mock管理，包括case创建、case列表、我的Mock；二是工具管理，主要是YAPI|Swagger接口导入；三是大盘统计，主要是调用统计的分析，包含每个业务域、调用量以及对应的Mock量、各业务线使用的分析等；四是权限管理，包括用户权限和用户组权限；五是拦截规则引擎，包括高并发支持、静默支持、生效范围和参数替换；六是一体化Mock工作台，可以集成APP、H5、微信小程序和支付宝小程序，自动接口抓包、一键功能，并支持YAPI|Swagger接口导入、接口参数自动获取、匹配规则参数自动生成；七是自动更新，底层代码改动，自动更新最新代码；八是环境稳定性，保证整体研发测试流程不被打断，Mock可被追溯。
HiMock整体流程
我们case的来源分为三部分，包括HiMock、Fox和第三方。左边这部分就是用户请求，分为后端请求和前端请求。后端请求我们通过Agent拦截到对应的协议之后，根据Mock、规则引擎去匹配对应的规则，如果能匹配到，就把对应的Mock结果返回出去。Agent的下载流程也有两部分，一是Atlas部署的时候，会去检查Agent是否存在，如果不存在，会自动下载到对应服务的原容器上或者ECS上面。二是添加或更新case的时候，也会去判断Agent是否存在。前端请求iOS是针对NSURLProtocol协议进行拦截和转发到对应的Mock规则引擎，去判断是否命中；安卓是针对OkHttp协议拦截和转发，其他协议也可以在这里进行兼容适配处理。
HiMock底层Agent设计
HiMock底层Agent设计主要分四方面，一是字节码拦截，我们经过大量的对比分析，最终选型ByteBuddy作为字节码拦截的底层框架，可实现低代码，迭代敏捷迅速开发。二是拦截协议，我们实现插件化模式开发，可快速实现拦截协议的开发与配置，支持多维度协议拦截。三是壳化Agent，对外暴漏一个premain的壳函数，可实现动态代码更新相关功能。四是后置处理，复杂链路信息，需要在Mock 返回之后，执行一些数据库操作、消息发送、地址回调等。
在HiMock底层Agent实现上，我们首先把Agent进行一个premain函数的壳化处理，再对各个协议拦截的Interceptor封装。HTTP协议请求，我们针对CloseableHttpClient、HttpClient、OkHttpClient和RestTemplate等等Class进行拦截。RPC协议，我们有进行RpcHandler Class拦截。针对Mq，我们有Hms进行拦截。同理，其他也是拦截对应的核心请求类，再进行协议的拦截。
HiMock规则引擎设计
HiMock规则引擎设计思路主要分三方面，包括高并发、兼容性和多端。在方案调研上，基于不同协议，拦截规则不尽相同，但是作为拦截收口，统一转为JSON进行参数匹配入参条件。最常用的JsonPath框架有fastJson、jackson、json-path和snack3，经过多轮压测，我们最终选型snack3，支持的选择器表达式更丰富，性能较优。在方案执行上，拦截规则判断时多条件支持，且支持多条件与或组合等。目前支持的条件有equals、not equals、contains、not contains、in等。在方案落地上，拦截规则参数根据入参自动生成，参数预期值智能匹配。
HiMock平台系统架构
HiMock平台包含WEB、核心功能、数据层、Agent和Mock服务。WEB主要有DashBoard、Mock管理、权限管理、工具管理和平台指南。核心功能主要有云容器自动部署、自动化部署、添加Mock、Mock列表、Mock日志、Mock规则、工具管理、权限管理、数据统计和用户手册。同时我们要适配一些拦截协议，如RPC、HTTP、TCP、MQ、MQTT、DB、ES。
数据层主要分为Mysql、Redis和ES，我们会把数据缓存到Redis里，再定期汇总到Mysql里，并把Redis里的数据进行清空，减轻缓存压力。Mock的服务请求被对应的Agent拦截到协议请求之后，Agent访问Mock服务设置的规则数据，拿到规则数据判断请求是否被匹配到Mock规则。
HiMock落地使用场景
HiMock落地使用场景有依赖测试、自动化测试、性能压测和并行开发等。依赖测试支持 case Mock生效日期和端到端的Mock生效范围，主要是为了避免某一个case过大影响实际的测试范围。自动化测试支持自动开启、关闭对应的Mock开关。性能压测支持一键静默，只要把静默开关打开，所有的调用Mock case都不会生效，这时所有的性能压测都会走原始的调用请求。并行开发支持生效范围界定和Mock参数动态调整等。当然我们在测试过程中不要过度依赖基于Mock的测试结果，Mock只是一种提效手段，基于Mock的测试无论如何多么的充分，都不能保证不会遗漏。一个完整的测试策略，一定是由基于Mock的测试和基于非Mock的测试共同组成，二者相辅相成，缺一不可。
HiMock平台能力介绍
这里介绍RPC接口的新增，在Mock标题里可以根据自己的场景设置标题，如助力车赔付，应用名称、iface、method是要拦截的对应服务以及它对应的method。在右边，我们也可以看到对应这两个应用名称，后面可以查看Atlas的配置,如果选择在ClientAppId进行Mock拦截，需要把对应服务的自定义启动参数中Agent启动命令配置上去。Mock环境里FAT和UAT都可以选择，同一个case多个环境同时生效。生效时间默认是永久生效的，如果填写生效范围，只会针对生效时间范围内走Mock逻辑；下面也有对应的是否开启的开关。添加规则这里，我们支持从用户请求日志里自动获取对应的请求有哪些参数，减少用户手动填入的复杂度。最下面的请求响应、执行日志和变更记录，主要用来查看预执行的时候对应这个规则能否匹配到，哪一步拦截失败，进而去调整Mock匹配规则。针对复杂场景，我们支持后置模拟回调，包括HMS、HTTP等。
这里是测试请求，测试请求自动填入，也可以根据实际情况进行动态调整，Mock结果即时校验。执行日志做到了执行过程的匹配，结果校验可以实时看到匹配规则是否正常匹配，以及匹配的返回结果是否是想要的。
接下来介绍前端一键Mock的功能，左边是我们的APP端，右边通过扫码APP-QrCode就可以看到左边菜单栏有自动抓包的链路信息，点击后会有接口对应的Request和Response。这里我们可以快速Mock对应接口的返回，或者是Mock异常的返回。
HiMock平台效果价值回收能力分析
我们主要从六部分进行HiMock效果价值回收能力分析，包括接口调用统计分析、Mock业务线覆盖统计分析、Mock占比分析、业务线Mock运营分析、Mock case统计分析和Mock次数、平均耗时统计分析。
这里是HiMock平台整体的调用统计分析，可以看到具体某个业务线、当天调用量和对应的Mock次数。左边是调用统计的趋势图，右边是业务线Mock次数的占比。
后续规划&探讨
Mock平台我们分三步走，第一步是测试小哥哥小姐姐通过手工Mock的方式人肉抓包Mock返回，后端Mock代码改动较大，费时费事费人，重复劳动严重。第二步是HiMock一体化Mock平台，可以支持全场景、多端Mock。前端自动抓包一键Mock，规则匹配参数自动生成，日志请求自动填充，极大提升了我们Mock case的整体效率。第三步是HiMock智能化，我们后续也会支持适配中间件DB、MQ类型协议的Mock，与仿真实验室、精准自动化的进一步结合，打造研发、精准测试、高效运营的一体化Mock，并打造智能出行Mock平台，能够self-learning自适应，以及更多场景的Mock支持。
The End
文末惊喜